home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Floppyshop 2
/
Floppyshop - 2.zip
/
Floppyshop - 2.iso
/
diskmags
/
0022-3.564
/
dmg-0055
/
542.txt
< prev
next >
Wrap
Text File
|
1997-04-16
|
12KB
|
299 lines
INFO-ATARI16 Digest Sat, 21 Oct 89 Volume 89 : Issue 542
Today's Topics:
CACHEXXX, (FATs, etc.)
Free RAM Comparison
GDOS, PP and outline fonts
High-speed modems and the Atari ST
Running from different environments
TOS 1.4 AUTO bug (2 msgs)
Turboboost with GCR
----------------------------------------------------------------------
Date: 20 Oct 89 18:07:07 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: CACHEXXX, (FATs, etc.)
Ritzert@DMZRZU71.BITNET writes:
>According to Allan, XXX must be exactly equal to the size of the FAT.
Please, this is a gross misunderstanding. If it *had* to be exactly
equal to anything, we would have written it to compute that thing
when it ran.
What I said is that there's little point in making XXX GREATER than
the sum of the FAT sizes.
>Related question: is it possible with tos14 to increase the cluster
>size, i.e. shorten the FATs dramatically and thus speed up the hd even
>further? Will CACHEXXX support such a configuration?
TOS 1.4 FAT handling is so fast, you wouldn't notice. My God, it's
DOZENS of times faster than TOS 1.2 FAT handling, and certainly
acceptably fast in its own right! When the FAT is entirely cached, a
Dfree() call on a 16MB partition takes under a second! That's fast
enough for me.
HDX on release 3.01 of the Atari Hard Disk Utilities disk allows you to
create partitions greater than 16MB in size. It accomplishes this by
making "sectors" on the disk appear to be larger than 512 bytes. A
cluster is always two sectors, but larger sectors means more data per
cluster, and therefore fewer FAT entries. Not all disk utilities use
Getbpb() to find out how big a sector is, so they won't all work with
this kind of partition. For maximum compatibility, therefore, this
feature only kicks in on large (>16MB) partitions.
CACHEXXX *does* support the larger sector size. No other cache program
can, because it doesn't know where to look to find the sector size it
should use. Don't use any other cache program if you have any
partition >16MB created by this HDX.
FYI: on the disk labelled 3.01 you will find HDX's version number is
3.00 and AHDI's version number is 3.01. If you use HINSTALL to make
your hard disk bootable, the version number you will see when it boots
is 3.01. This is all well and good. If your hard disk driver, whether
installed by HINSTALL or loaded from your AUTO folder as AHDI.PRG, says
it's version 3.00, GET THE UPDATE. AHDI and bootable disks version
3.00 are DEADLY to data.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 20 Oct 89 13:15:43 GMT
From:
cs.utexas.edu!mailrus!sharkey!cfctech!teemc!ka3ovk!lake@tut.cis.ohio-state.edu
(Marshall Lake)
Subject: Free RAM Comparison
Does anyone know if there is a difference in the amount of free RAM
on a stock 520ST vs a stock 520STFM?
Marshall Lake
lake@ka3ovk
------------------------------
Date: Fri, 20 Oct 89 23:01:46 EDT
From: David Megginson <MEGGIN@vm.epas.utoronto.ca>
Subject: GDOS, PP and outline fonts
Actually, there is only one package using outline fonts on the ST, but
it's Calamus and not Publishing Partner. PP uses some rather pathetic
outline fonts on the printer, but it still uses raster fonts for the
screen. Furthermore, Calamus uses real, licensed Compugraphic fonts.
Besides, what's all this about? Apple is still developing its outline
font system. Certainly, a Mac can output to a Postscript device which
uses outline fonts, but so can an ST or IBM. Right now, Macs use
raster fonts just like GDOS, except the output resolution is not as
good on the imagewriter (I imagine). The only system I know of with
outline fonts is the NeXT, and the __only__ full DTP package with
outline screen fonts is still Calamus (Mac users, turn green with
envy!!!!!).
David Megginson, Centre for Medieval Studies, Toronto
------------------------------
Date: 21 Oct 89 03:05:10 GMT
From: cca.ucsf.edu!wet!logic@cgl.ucsf.edu (Henry Kwan)
Subject: High-speed modems and the Atari ST
In article <4649c632.14a1f@force.UUCP> covertr@force.UUCP (Richard E. Covert)
writes:
>
>US Robotics has had an outstanding offer to BBS Sysops, and also to USENET
>Node Adminstrators. In brief you can buy an USR 9600 HST modem for the low
>price of $495.00. This has made the USR 9600 HST very popular with ST BBS
>sysops. The the majority of ST BBSes which use a 9600 baud modem use the
>USR 9600 HST. So, just call around and look for ST BBSes which are 9600
>buad and you can talk to lots of folks!!
>
If you think that the Sysop Program from USR is outstanding, wait til you
take a look at the Dealer Demo Program from USR. It'll blow you off your
feet.
Currently, all USR Courier HSTs shipped are 14400 bps. The 9600 bps HSTs
had been discontinued for some time now.
>
>Your transmission speed depends greatly on the quality of the phone line, but
>1625 cps sounds typical for that modem. You won't get that high on some
>boards though. Some of the loss can be attributed to the TOS, it just can't
>handle data that quickly off of the serial port.
>
Actually, 1625 cps is not typical for the 14.4 HST. The USR manual itself
lists 1740 cps as typical when using HST mode and MNP level 4. Some have
reported on the HST Echo cps ratings as high as 2000.
>That is typical also for Y-modem transfers. The only program that I know of
that
>gets >>800 cps for uploads is ST TERM, with its built in Z-modem protocol.
>
I was using Zmodem. That's why I wanted to know if Ymodem-G would improve
on that dismal cps rating. Currently, the best I can get is ?900 cps using
Ymodem while in v.32 mode. Interestingly enough, Zmodem gives me worse
throughput when I use it to upload.
>
>I have had my USR 9600 HST for 6 months and have found that it is very
reliable,
>and has paid back it costs via lower phone bills already!! And USR has sent me
>to updates (firmware) to it already for free!! That's good support!!
>
>Rich Covert
It's a good modem, that's for sure. I am trouble by the reports of
incompatibilities though. It seems that the Dual Standard has trouble
connecting to some modems at 2400 bps and even some modems at 9600 bps
(v.32). The frequent firmware updates are troubling also. I bought my
modem less than a month ago and I find that my firmware is two or more
revisions behind already!
By the way, a small nitpick. The USR Courier HSTs are not 9600 'baud',
they're 2400 'baud'. :-)
--
Henry Kwan | AppleLink: D0690
FWB, Inc. | CompuServe: 71320,1034
2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov
San Francisco, CA 94109 | UUCP: ?claris,hoptoad,lamc,ucsfcca?!wet!logic
------------------------------
Date: 20 Oct 89 13:10:59 GMT
From:
mailrus!accuvax.nwu.edu!tank!ux1.cso.uiuc.edu!dino!sharkey!cfctech!teemc!ka3ovk
!lake@tut.cis.ohio-state.edu (Marshall Lake)
Subject: Running from different environments
In article <30200004@inmet> hedger@inmet writes:
>
>I just got my ST so I'm a real novice, and this may seem like a really
>naive question but here goes: Is your program set up to use or try to
>use the hard disk at all? When your program was first installed was the
>hard drive on? At installation time is it possible that the program in
>question put a file on the harddisk that he needs to see to initialize
>and run?
>Just groping.
>
>
Thanks for your help. No, it's nothing like any of that. The program
reads and writes files but it just uses whatever it was booted on ...
floppy or hd. There's something else.
It appears I'm just groping, also.
If you have any other thoughts, pass them on please.
Marshall
lake@ka3ovk
------------------------------
Date: 21 Oct 89 00:09:12 GMT
From:
mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!bnr-vpa!bnr-fos!bigsur!bnrgate!bcar
a13!fortinp@tut.cis.ohio-state.edu (Pierre Fortin 1573589)
Subject: TOS 1.4 AUTO bug
Has anyone else experienced the following problem?
I installed TOS1.4 in my Mega 2. After booting up the system
I installed NeoDesk 2.05 and used the new AUTO feature in the
"Install Application" to make NeoDesk auto-start on bootup.
Next, I re-booted my system and NeoDesk auto-started as
expected. I then double-clicked on UniTerm and was greeted
with two bombs. OK, only two changes to my environment:
TOS 1.4 and Install Application AUTO versus using STARTGEM.
I removed the AUTO install feature and re-booted. Then, I
started NeoDesk 2.05 by double-clicking on NEOMASTR.PRG and
got my favorite desktop. Then double-clicked on UniTerm as
before and everything is fine. I repeated all of the above,
and it seems to me that there is a bug in the TOS1.4 AUTO-
start feature.
I also talked to others in our club who have experienced
similar two bomb crashes when using this new "feature".
Atari?
Cheers,
Pierre Fortin
Ottawa, Canada
------------------------------
Date: 21 Oct 89 03:25:24 GMT
From: milton!blake!charlop@beaver.cs.washington.edu (Aaron Charlop)
Subject: TOS 1.4 AUTO bug
In article <122@bnrgate.bnr.ca> fortinp@bcara13.bnr.ca (Pierre Fortin 1573589)
writes:
>Has anyone else experienced the following problem?
>
>I installed TOS1.4 in my Mega 2. After booting up the system
>I installed NeoDesk 2.05 and used the new AUTO feature in the
>"Install Application" to make NeoDesk auto-start on bootup.
>
>Next, I re-booted my system and NeoDesk auto-started as
I also have had a problem with the autoboot command. I installed my
Terminal emulation program AnsiGraf to autoboot. However, when I my
computer boots, the program can't access the modem. If I exit the program
and restart it from my hd, it works fine. Also when I exit from the program
after it has autobooted, my desktop comes up in the default colors not the
ones defined in my desktop. I have to call up the control panel from
MultiDesk to reset the colors.
Anything Atari?
On TOS 1.4 incompatibility. It seems that OmniRes will not work with TOS
1.4. Anybody have a new OMNIRES.INF that will work with 1.4.
I have version 3.01, maybe I wasn't informed of an update.
--
Aaron the Alchemist
Charlop@uwachem.washington.edu
"Yes, I really am a honest-to-goodness alchemist" Me
------------------------------
Date: 19 Oct 89 14:51:33 GMT
From: att!drutx!druwy!dlm@ucbvax.Berkeley.EDU (Dan Moore)
Subject: Turboboost with GCR
in article <761@utacs.UTA.FI>, jackin@utacs.UTA.FI (Markku M?enp??) says:
> Has anybody succeeded in using Spectre GCR with faster
> processors (16Mhz) ? I would like to get my MEGA faster and
> especially would like to see Spectre GCR roaming in 16 Mhz.
The Spectre GCR works with all of the currently available 16
Mhz processor upgrades. Just don't expect it to run twice as fast,
most of the upgrades only offer about a 5% performance increase. The
upgrades are really limited by the low performance of the memory in the
ST (low compared to a 16 Mhz CPU). As far as I know only one of the
upgrades supplies a large performance boost since it has 32K of cache
memory, that allows the CPU to run at 16 Mhz with no wait states most
of the time. With the cache the performance increase can be as large
as 100%, the average boost is about 50%.
Dan Moore
AT&T Bell Labs
Denver
dlm@druwy.ATT.COM
------------------------------
End of INFO-ATARI16 Digest V89 Issue #542
*****************************************
=========================================================================